IaC Cloudformation スタック管理のいろは

CloudformationはIaCツールの一つであり「宣言型IaCツール」に分類される

Cloudformationでインフラを管理する際、迷うポイントが2つある

スタックをどう分ける？

スタックに含めない方がいいリソースはある？

この迷いは、他の宣言型IaCツールでも発生する。

IaC定義をどう分けるといいのか。1つのインフラを1つのIaC定義で管理するか。

IaC定義に含めない方がいいコンポーネントはあるか

このページでは、2つの迷いポイントに対する考え方をCloudformationを例にして記録しておく。

スタックをどう分ける？

hr.icon

分け方に正解はないと言ってしまえばそれまでなのだが、それでも「こういう分け方ありだよね」ていうお話をする。

そもそも、1つのインフラを1つのスタックで管理するのは、やはり良くないのだろうか？

あまりお勧めはしない。そこにはいくつかの理由がある。

理由①：スタック定義内のリソース種類・数が半端ないことになって、人間によるインフラ構成の把握が難解になる

理由②：リソースの変更・削除を積極的に行えなくなる

理由③：他のインフラへの構成の使い回し・再利用がしにくくなる

詳細説明

理由①：

プログラミングの世界では「人間が読みやすい・理解しやすい状態を徹底しろ」ていう原則があるが、これはIaCでも同じことが言える。

1つのスタックに色んな種類のリソースを沢山詰めこむと、スタック定義の内容が複雑になって、インフラ内に何の機能が存在してるのかが把握しにくくなってしまう。

1つのインフラを複数のスタックに切り分けておくと、インフラに何の機能があるかを人間が理解しやすくなる。

反論として「スタック定義の書き方やディレクトリの分け方を上手くやれば、解読しにくい状況を防げるのでは？」というものがあると思う。全くその通りである。

ただ、スタックを分けようとすると、スタック定義のファイルも自然に別れることになるので、あまり深いことを考えずに、人間が理解しやすい状況を作り出せるという利点はある。

理由②：